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(57) Abrege/Abstract: 

This invention relates to a system for interactive on-demand delivery of multimedia using a multicast broadband backbone 
network transmitting IP- configured digital multimedia (e.g. television) signals. More particularly the on-demand system provides 
, inter alia, a Virtual Digital Video Recorder functionality. A system manager provides interactive access to the multimedia 
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(57) Abrege(suite)/Abstract(continued): 

signals by a subscriber through either a decoder in a set top box (connected to a television) or a decoder in a computer 
(connected to a monitor) configured for converting the IP format signal into a format for display on the television or monitor. A 
central multimedia storage means is located within the network and remote from the subscriber for storing multimedia content 
An on-demand component is configured for receiving a deliver request from a subscriber for the stored content, for locating the 
requested multimedia content from the storage means and for delivering the requested multimedia content for display on the 
television or monitor. The multimedia content is stored in the storage means in a format configured for locating same in response 
to a deliver request. An interactive program guide (IPG) may provide access to the multimedia signals and the multimedia 
signals are transmitted through the network according to scheduling corresponding to the interactive program guide. The on- 
demand component receives a record request (which includes broadcast channel and time information identifying the 
multimedia content and may utilize the IPG) from a subscriber and stores the multimedia content in response to the record 
request 
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ABSTRACT 



This invention relates to a system for interactive on-demand delivery of 
multimedia using a multicast broadband backbone network transmitting IP-configured 
digital multimedia (e.g. television) signals. More particularly the on-demand system 
provides , inter alia, a Virtual Digital Video Recorder functionality. A system manager 
provides interactive access to the multimedia signals by a subscriber through either a 
decoder in a set top box (connected to a television) or a decoder in a computer 
(connected to a monitor) configured for converting the IP format signal into a format 
for display on the television or monitor. A central multimedia storage means is located 
within the network and remote from the subscriber for storing multimedia content. An 
on-demand component is configured for receiving a deliver request from a subscriber 
for the stored content, for locating the requested multimedia content from the storage 
means and for delivering the requested multimedia content for display on the 
television or monitor. The multimedia content is stored in the storage means in a 
format configured for locating same in response to a deliver request. An interactive 
program guide (IPG) may provide access to the multimedia signals and the multimedia 
signals are transmitted through the network according to scheduling corresponding to 
the interactive program guide. The on-demand component receives a record request 
(which includes broadcast channel and time information identifying the multimedia 
content and may utilize the IPG) from a subscriber and stores the multimedia content 
in response to the record request. 
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DIGITAL INTERACTIVE DELIVERY SYSTEM FOR 
TV/MULTIMEDIA/INTERNET WITH ON-DEMAND APPLICATIONS 

Technical Field 

This invention relates generally to a system for the delivery of IP-configured 
digital multimedia (e.g. television) signals to a subscriber (consumer) using multicast 
transmissions over a broadband network and, more particularly, to a system for 
interactive on-demand delivery of multimedia providing, inter alia, a Virtual Digital 
Video Recorder functionality. 

Background 

With the proliferation of TV broadcast providers delivering regular programming 
as well as specialty services, such as pay per view and first run movies, TV viewers 
are frequently faced with scheduling problems in order to view their favorite programs. 
The scheduling problem is even more severe in a typical household having one 
television with several potential viewers each having their own viewing preferences. 
The known video cassette and digital video recorders (VCRs and DVRs) which attach 
to televisions enable consumers to record a television program on a current or 
scheduled basis but they do not permit one to record two programs simultaneously 
and, further, have associated with them many inconveniences such as the need to 
have a usable recording medium (i.e. tape or disc) at hand at the time one wishes to 
record a program and considerable operational time and know-how with respect to 
use of the hardware which has become more complex with the addition of pre- 
programming features which utilize program codes. 

TV broadcasts are currently delivered through service providers such as cable 
companies, and satellite operators and, of course, direct broadcast reception via 
traditional antennas and rabbit ears. Conventional cable service requires the 
installation of a dedicated cable to the subscriber's residence. Satellite broadcast 
service requires that the user have a satellite dish located on or somewhere close to 
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their residence. Antennas and rabbit ears are generally limited to the reception of 
local programming. Additionally, program delivery via all of these services is at the 
convenience of the service provider or broadcaster and, hence, the user or subscriber 
must arrange his or her schedule to coincide with program availability. 

It is well known that the purchase of personal computers by homeowners has 
increased dramatically in recent years. Previously, these computers were used 
primarily for word processing, accounting and other record keeping purposes and also 
for Web surfing and email using modems and conventional telephone service for 
connecting to the Internet. Frequently, however, these modems have a low baud rate 
making the transfer of data, particularly graphics, unacceptably slow. More recently, 
however, with the development of Digital Subscriber Line (DSL) technologies such as 
ADSL an expanded scope of broadband capacity exists for the copper wire (twisted 
pairs) at the user-end of the telecommunications network and this capacity may be 
used to provide enriched communications services to consumers including multimedia 
such as television and video. 

With the increased availability of broadband backbone and delivery networks, 
and increased usage of PCs by consumers, an increasing demand is evolving for on- 
demand multimedia services which enable consumers to plan their entertainment to 
their own schedule and interests rather than tailor their entertainment viewing habits to 
a service provider's broadcast schedule. Moreover, there is a need to overcome the 
inherent limitations presented by the usual home installations of VCRs and DVRs 
connected to television sets. The fixed hardware of such machines is inherently time- 
limited and any upgrades or design changes to implement new services must be done 
physically either by installing new hardware/software packages in the machine or, 
more likely, by buying a new machine to replace an outdated one (causing much 
expense to the consumer). Further, from the perspective of consumers, using VCR 
and DVR machines to record and view broadcast multimedia is undesirably machine- 
limited in that one mush have a separate VCR/DVR machine connected to its own 

2 
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television in order for two persons in a household to watch different recorded 
programs. Further, from the perspective of multimedia content providers, home usage 
of VCR/DVR machines to record proprietary multimedia content undesirably renders 
that content fully in the hands of the consumer (i.e. in the form of a video tape or disk 
5 on which a program is stored) and, thus, beyond the control of the multimedia content 
provider whose interests are best served in an environment providing digital rights 
management. 

Summary of the Invention 

10 In accordance with the invention there is provided an on-demand multimedia 

delivery system and method for use in an integrated multimedia broadcast delivery 
system extending from a broadcast provider to a subscriber. The broadcast delivery 
system comprises means for providing multimedia signals configured according to IP 
(Internet Protocol) format for multicast transmission over a broadband network and a 

1 5 system manager for providing interactive access to the multimedia signals by the 

subscriber through conversion means, being either a decoder in a set top box and a 
television or a decoder in a computer and a computer monitor, configured for 
converting the IP multicast format signal into a format for display on the television or 
monitor. The on-demand delivery system comprises central multimedia storage 

2 o means located within the broadcast delivery system and remote from the subscriber 

for storing multimedia content. An on-demand component is configured for receiving a 
deliver request from a subscriber for the stored content, for locating the requested 
multimedia content from the storage means and for delivering the requested 
multimedia content to the conversion means for display on the television or monitor. 

2 5 The multimedia content is stored in the storage means in a format configured for 

locating same in response to the deliver request. 

An interactive program guide (IPG) is preferably provided to the subscriber by 
the system manager of the broadcast delivery system for said access and the 

3 o multimedia signals are transmitted through the network according to scheduling 
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corresponding to the interactive program guide. The on-demand component is further 
configured for receiving a record request from a subscriber and for storing the 
multimedia content from the signals in response to the record request. The record 
request includes broadcast channel and time information identifying the multimedia 
content and may be made from the interactive program guide. The multimedia 
content may correspond to one or multiple broadcast programs. The record request 
may be received any time up to the end of transmission of the signal corresponding to 
the program. 

Brief Description of the Drawings 

The present invention will now be described in greater detail with reference to 
the following drawings in which like reference numerals refer to like elements 
throughout. 

Figure 1 is a block diagram of a preferred multimedia broadcast delivery system 
in accordance with the invention (hereinafter referred to as the "delivery system"); 

Figure 2 is a further block diagram of the delivery system; 

Figure 3 is a schematic block diagram of the elements of the delivery system 
and the operational components of the system manager component 40 (hereinafter 
referred to as the "system manager"); 

Figure 4 is a schematic operational diagram of the delivery system and system 
manager; 

Figure 5 is a schematic diagram illustrating a layered relationship of the 
components of the delivery system and system manager; 

Figure 6 is an exemplary interactive program guide (IPG) generated by the 
system manager for display by a television through a set-top box; 

Figure 7 is another exemplary interactive program guide (IPG) generated by the 
system manager for display by a personal computer (PC); 

Figure 8 is an exemplary player window and virtual remote control generated by 
the system manager for display by a personal computer (PC); 

Figure 9 is an exemplary virtual remote controller, showing the basic functions 
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available, as generated by the system manager for display by a personal computer 
(PC); 

Figure 10 is the virtual remote controller of Figure 10 but showing the "options" 
box selected and the various available optional functions displayed; and. 

Figure 1 1 illustrates a system for concurrent transmission of MPEG-1 and 
MPEG-2 encoded signals; 

Figure 12 shows three exemplary interactive television or computer display 
windows (GUIs) generated by the virtual DVR on-demand application of the present 
invention by which the user may instruct the recording of a designated program 
selected from an IPG (a), a program display (b) or a main menu (c); 

Figure 13 is an exemplary interactive television or computer display window 
(GUI) screen generated by the virtual DVR on-demand application of the present 
invention by which the user may instruct the recording of a designated program by 
selecting a channel, day and time; 

Figure 14 is an exemplary interactive television or computer display window 
(GUI) generated by the virtual DVR on-demand application showing a sample Play 
List of a current program recordings which may be played; 

Figure 15 is an exemplary interactive television or computer display window 
(GUI) screen generated by the virtual DVR on-demand application of the invention 
showing the program information for a program selected for recording and providing 
recording options; 

Figure 16 is another exemplary interactive television or computer display 
window (GUI) screen generated by the virtual DVR on-demand application of the 
invention showing the program information for a program which has been selected for 
recording and providing play and delete options for that recording; 

Figure 17 is an architectural schematic diagram of the Virtual DVR system 

described herein; and, 

Figure 18 is a schematic model diagram illustrating the Administration and 
Operations aspects of the Virtual DVR system described herein. 
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Detailed Description of a Preferred Embodiment 

Figure 1 is a high-level block diagram of the basic elements of an exemplary 
multimedia delivery system as contemplated herein; for the convenience of the reader 
a glossary of several terms used herein, setting out their well-known meaning in the 
communications art, is provided herein as Appendix A. 

At the head-end 24 of the system a video source 12 retrieves multimedia/ 
television/Internet signals for broadcast from various sources such as satellites in the 
form of MPEG-compliant, Multi-Program Transport Streams (MPTS) and these signals 
are delivered to (analog-to-digital) video encoders 14 or (digital-to-digital) transcoders 
130 where they are converted to one or more IP Multicast Single-Program Transport 
Streams (SPTS). The encoder 14 encodes analog video and audio inputs. The 
transcoder 130 decodes digital video and audio signals, perhaps high-speed MPEG 
video SPTS or MPTS, and re-encodes them into a format which is suitable for the 
subscriber device being STB 22 or PC 30. Each IP multicast SPTS is a packetized 
MPEG stream which is subsequently sent out over a broadcast provider network 16 
to a Digital Subscriber Line Access Multiplexer (DSLAM 18) 18 which might be located 
in a telephone company central office. The DSLAM 18 serves two purposes: firstly, it 
connects broadband lines in the transport network to xDSL lines in the access network 
and, secondly, it separates high-speed data from voice data, putting high speed data 
on the data network and low speed data on the conventional phone system. This 
allows concurrent use of the telephone and the system manager components on the 
same phone line. An IP Multicast signal from the DSLAM 18 is delivered to a 
subscriber's residence over an xDSL link such as an Asymmetric Digital Subscriber 
Line (ADSL), where it is received by an ADSL modem 20 and delivered to a client 
server such as a set top box (STB) 22 or a PC 30. More precisely, xDSL lines 
connect the DSLAM 18 to an ethernet interface on the xDSL modem, and a 10BaseT 
cable connects the ethernet interface on the xDSL modem to an ethernet interface 
card on the set-top or PC. 

6 
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The delivery system comprises software for enabling a service provider to offer 
broadcast television over Internet Protocol (IP), including IP multicast and unicast, 
which allows channel browsing by selecting and retrieving IP multicast streams. IP 
multicast is characterized by the sending out of data to distributed servers on a 
5 multicast backbone network. For large amounts of data (including video 
transmissions). IP multicast is more efficient than normal Internet unicast 
transmissions because the server can broadcast a message to many recipients 
simultaneously. Unlike traditional Internet traffic that requires separate connections 
for each source-destination pair. IP multicasting allows many recipients to share the 
i o same source. This means that just one set of packets is required to be transmitted for 
all the destinations. 

If the bit rate of the satellite transmission is not greater than 1 MBPS the signal 
may be transcoded directly to IP multicast MPEG. This takes existing digital 

1 s transmissions from a satellite and reprocesses them for delivery on an IP Multicast 

delivery system. The advantages of this are that it lowers the cost of head-end 
equipment 24 (satellite dish, etc.) by replacing the encoder 14 with a transcoder 130. 
and it also maximizes the quality of the signal being delivered from a digital signal 
source at the head-end (since it is only digitized once, and remains that way). At the 

2 o broadcast provider location a split/distributed head-end (signal from satellite) can also 

be employed to optimize transport facility cost. As shown in Figure 2. the video 
source may be a satellite located at head-end 24, which may be operated by a 
broadcast provider such as a telephone company or other service provider. The head 
end 24, and a system server complex 40. interface with a broadband network 26 

2 5 through an IP multicast router 28 and a transport router 42, respectively. 

Digital video equipment gathers, processes, and distributes video. This 
equipment can include satellite dishes, satellite receiver units, encoders, 
remultiplexers. video servers, and IP gateways. Encoders and remultiplexers process 

3 o live video, and video servers support the distribution of stored video. Encoders and 
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remultiplexers perform two main functions: firstly, they convert individual MPEG- 
compliant, Multi-Program Transport Streams (MPTS) from satellite into one or more IP 
multicast Single Program Transport Streams (SPTS) in real time and, secondly, they 
multicast the IP SPTS's over the service provider s IP network. 

The server complex of the management system 40 (also referred to herein as 
the "system manager", "DTVM" or ' Digital TV Manager") contains vital software 
components and comprises two main servers, namely, a system manager (DTVM) 
server and a database server. The DTVM server incorporates standard web server 
software, and other standard software, such as JVM (Java Virtual Machine), 
DHCP/BootP, RPC, and NFS. The database server runs standard database software 
and stores all data for consumers (such as IPG data) including events data. 

The broadband network is IP Multicast compatible and has sufficient bandwidth 
capacity to transport encoded video signals. A subscriber to the broadcast service 
has access to the network via a broadband link. Examples of broadband links include 
Digital Subscriber Line (xDSL) (such as Asymmetric Digital Subscriber Line (ADSL)) 
Asynchronous Transfer Mode (ATM), Frame Relay, Synchronous Optical Network 
(SONET), Local Multipoint Distribution System (LMDS), Hybrid Fiber Coax (HFC), or 
Fiber To The Home (FTTH). xDSL is of particular significance because it allows a 
broadcast provider to deliver programming to residential communities over existing 
copper wire (i.e. the twisted pairs linking the customer premises to the 
telecommunications network) without having to delay introduction of the service until 
the other access technologies become widely available. 

The subscriber can access the TV broadcast with either a personal computer 
(PC) 30 having an associated monitor or a television 32 with a set top box (STB) 22 
such that, in essence, the STBs and PC's act as network computers. Each PC and 
STB is configured from downloaded multicasted data sources and uses a head-end 
server for persistent storage. Accordingly, the consumer access 20 operates out of 
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memory (RAM) rather than a hard disk and this means that there is no dependence at 
the consumer end on moving parts and this, in turn, provides improved performance, 
decreased costs, reduced noise and fewer equipment failures and facilitates automatic 
software upgrades. Dependence on servers at the consumer-end is minimized and 
5 servers are not required for regular television viewing or Web browsing. Once an STP 
or PC boots up, basic television viewing depends only on the availability of the video 
source and the associated network. 

The set top box 22 includes decoding circuitry for decoding MPEG-1 and/or 

1 o MPEG-2 as well as IP Multicast. To view the broadcast from a PC 30 it is equipped 

with appropriate software and may optionally be equipped with an associated MPEG 
card. The STB 22 is activated by an interface unit such as a keyboard or remote 
device 23 and the PC 30 interfaces the subscriber via a keyboard and/or mouse. 

t5 As shown in Figures 1 and 2 the broadcast provider is able to access television 

broadcast signals from various sources such as satellite 12, off-air broadcast or a 
static source such as a storage medium containing movies or the like. The sen/ice 
provider encodes the broadcast signal (MPEG) and makes it available to service 
subscribers (i.e. consumer users of the delivery system) through the broadband 

2 o network 26 using the Internet protocol (IP). The system manager 40 is linked to the 

network 26 via a transport router 42 and provides end-to-end management of sen/ices 
and resources provided by the integrated broadcast delivery system. 

Figure 3 shows the architectural configuration of the delivery system including 

2 5 the consumer end appliances (PC and/or STB), the broadband IP network and the 

DTVM components. Figure 3 also shows another aspect of the deliverable services, 
i.e. Internet access 56. User access to the network is through an xDSL access 
element such as an ADSL Transmission Unit (ATU) 20. The broadband IP network 
and services section includes access router 28 and the transport network 'cloud* 26. 

3 o The transport network 26 has access to various components running parallel to the 
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head-end, namely, video-on-demand (VOD) 50 and near video-on-demand (NVOD) 
52, and the following additional "on-demand" applications: virtual digital video recorder 
(VDVR) 90 90?, "timeless" TV application and TV-on-demand, as well as e-mail 54 
and Web access through the Internet 56. 

For standard broadcast signals and pay-per-view (PPV) or near video on 
demand (NVOD) services a multicast IP protocol is used in order to make efficient use 
of bandwidth. With this protocol numerous subscribers can have access to a program 
at the same time. For true video-on-demand service (VOD, VDVR, timelessTV and 
TV-on-Demand) f however, a unicast IP protocol is used. The DTVM software 
application 40 provides several features to a subscriber of the delivery and manager 
systems. These include but are not limited to customer profile management 68, billing 
and reporting 84, Interactive Program Guide (IPG) access 60, connection and channel 
packaging 104 including a self-service option 71, channel blocking (not shown), on- 
line multilingual support (not shown) and information banner functions 64. 

Figure 4 is an operational schematic diagram of the broadcast delivery system. 
The Digital Subscriber Line Access Multiplexer (DSLAM 18) 18 at the edge of the high 
speed IP network is a network device which may be located at a telephone company 
central office. The DSLAM 18 enables a telephone company to provide subscribers 
with xDSL, such as ADSL, technology and to connect the subscriber to a fast 
backbone such as an ATM transport network 26. The ATM network routes the 
various broadcast services, previously mentioned, to the DSLAM 18 which, in turn, 
makes them accessible to subscribers via their PC 30 and/or STB 22. Figure 5 shows 
in a layer format the relationship between suppliers of the various components of the 
overall TV broadcast delivery system. At the bottom layer (layer 1) are the equipment 
and appliance suppliers such as set top box and computer suppliers, etc. The second 
layer (layer 2) represents the service provider such as a Telco who make available the 
IP and other protocols necessary to transport the video and furnish the manager 
application functions between the service provider and subscriber. The third layer 
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(layer 3) includes the application functionality of the DTVM. As indicated in Figure 5, 
these include consumer 80 and administration 82 service components, reporting and 
billing components 84 and IPG 65 and browser 75 components. 

The system manager (DTVM) utilizes some standards-based components and 
its components can be categorized into two groups, namely, client (subscriber) and 
server components. Client components run locally on the STB or PC and are 
collectively referred to herein as subscriber device components. They provide three 
capabilities: firstly, they provide viewing capability based on a user profile; secondly, 
they provide business rules based on a user profile that specify permissions and 
restrictions to resources; and. thirdly, they forward events and registration information 
to the server. Registration information includes, among other things, the IP address of 
each device. Server components generate, manage, and update the data that is sent 
to the STB or PC. Server components also organize data according to a user profile. 
The DTVM may run on a Sun Solaris platform (this currently being a preferred 
platform) but the platform used will be dictated by the service provider based on its 
needs. 

The subscriber device component of this embodiment uses four components 
that are installed the STB or PC, namely, an MPEG player, a browser, a networking 
API and a windowing API. The MPEG player supports video viewing and the browser 
supports Web browsing. The networking API supports the protocols used by the 
DTVM applications such as IP. NFS, and MPEG. The windowing API specifies what 
interface screens can be drawn and how. Within the DTVM software there are many 
components which perform the following functions: management of the display of all 
content (including MPEG video. Interactive Program Guide (IPG), and web pages), 
processing of remote control commands, providing time measurement ability, sending 
of events data to the server, listening for updates from the server in the IP multicast 
stream, prompting the user for registration input, sending retrieved data to the server 
for further processing, and registering STB or PC with the DTVM/service provider. An 
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SNMP Management Information Base (MIB) component is also provided in each STB 
or PC which, conventionally, uses SNMP to query and reset remote indicators (i.e. 
receives and responds to SNMP compliant messages) and, unconventionally, uses 
SNMP to update consumer specific data on client devices for purposes of remote 
diagnostics, notification of new data availability and reminders or news items. 

Several "off the shelf server components are used by the system manager and 
they play the following roles: 

• A Web server stores servlets that support administration (provisioning, remote 
diagnostics, etc.) and self service (pay-per-view, channel blocking, etc.) transactions 
and standard products such as the Netscape™ Enterprise Server and Apache™ are 
used in this. 

• JDBC (Java™ Database Connectivity) and SQL*NET™ are used to enable the Java 
applications of the DTVM to access the database. 

• A database stores all data for consumers, the IPG, events, etc., and the 
persistence architecture of the DTVM is able to support multiple database models, 
including Oracle™ and SyQuest™. 

• The operating system layer provides BootP/DHCP and NFS components to support 
set top box boot up and profile retrieval. 

The DTVM server components are written in the Java™ programming language 
and their roles are as follows: 

• DTVM uses two daemons (i.e. automated background processing modules): 
multicast and Remote Procedure Call ('RPC'). The multicast daemon broadcasts 
multicast data content to specific multicast addresses to deliver data to the STB or PC. 
The RPC daemon forwards events data and registration information from the STB or 
PC to the database server. The RPC daemon also has an RMI (Remote Method 
Invocation) interface to support distributed Java applications. Both daemons use the 
Sun™ native JVM (Java Virtual Machine). 

• Batch transactions automate the IPG update process. The IPG update process 
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consists of three phases: in phase one a retrieval process uses FTP to retrieve a data 
file from the data provider that contains television programming data, in phase two a 
mapping process maps the data file to the database and in phase three a preparation 
process formats and forwards the IPG data to the multicast server. 

• Servlets may be used to generate HTML pages that support service administration 
and self service transactions and also to invoke persistence architecture components 
in order to make changes to the database. Alternatively, JSP (Java Servlet Pages) 
and applets may be used (instead of servlets) if increased configurability and 
interactivity of self-service screens is desired. 

• Persistence architecture components facilitate connections and exchanges between 
Java business objects and database tables. 

The subscriber accesses the IPG through components in the STB 22 or PC 30. 
Some memory may be available locally for storing specific information, or alternatively, 
the entire IPG may be maintained in the network. The subscriber uses the remote 
control or keyboard/mouse 23 for interfacing with the IPG displayed on the television 
or computer monitor the interactive nature of the IPG gives a subscriber control over 
many aspects of the broadcast system. Program scheduling information may be 
presented in a form as shown in Figures 6 and 7 (Figure 6 showing a STB IPG and 
Figure 7 showing a PC IPG). With this listing displayed on a TV monitor or computer 
display the user can scan the channel line-up 126 and program schedule cells 123 
listed on the display, choose, highlight and then click on a desired program and the 
television or computer will then automatically retrieve the selected IP multicast stream. 
In addition, as indicated in Figures 6 and 7, another clicking configuration may display 
a brief information banner 121 with relevant data concerning program content and 
timing for a highlighted selection (i.e. "Travel with Beth" in Figure 6 and "Debbie 
Travis' Painted House" in Figure 7). Additionally, a user can click on a desired 
program and select it for recording (i.e. utilizing the VDVR application). The DTVM in 
conjunction with the IPG provides a subscriber with the ability to channel browse for 
TV programs and/or Web sites and order pay-per-view programs. In the preferred 
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embodiment a seven day channel lineup with scheduled automatic refresh is provided. 
The IPG client software is automatically updated by the system at regular intervals. 
The data provider must provide programming data in a pipe delimited text file once 
every 24 hours, or such other period as may be appropriate. The DTVM system 
5 transfers data from the text file into the service providers database and then 

multicasts IPG data from the service provider's database across the network to the 
user on the PC display or television. 

In the PC environment, as shown by Figure 7, the IPG information is displayed 
10 on the PC s monitor for programs that are currently in progress as well as future 
scheduled programs. Using a keyboard or mouse, the consumer is able to: use a 
seven-day schedule for available channels; by browsing the IPG window, change the 
day by selecting another day from the Scheduled Day controller! 24 which is operative 
as a drop down control ; quickly access other times in the current day by a Quick 
15 Access controller 125; obtain the details, in the form of a Show Block 127 and an 
Information Block 121, for a show when it's clicked; retrieve the IP multicast stream 
corresponding to the selected channel when a Program Schedule cell 123 is double 
clicked (or the <Enter> key is pressed) if the show is currently running. The 
Scheduled Day controller 124 is a list box giving the consumer the possibility to select 
2 o the day he/she is interested to browse. When the IPG window is activated, the current 
day is displayed. All future dates are shown as the day of the week followed by the 
calendar month and day of month. The Quick Access controller 125 is also a list box 
providing an easy and fast access to a specific daytime. A cell of the Channel Lineup 
126 column contains the station call letters and channel number for the station that is 

2 5 broadcasting the listed programs. On operation of the IPG the top station of the 

channel lineup is the channel currently playing unless no station is playing in which 
case the top one is the first available. 

The data associated with the Program Schedule Cells 123 is controlled 

3 0 according to the following. When the IPG window is activated, the 7 day IPG data is 
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already prepared and stored in the local memory of the PC (the client device). The 
system selects the IPG data of the selected day beginning with the current time and 
displays it in the IPG window. When another day is selected by the Scheduled Day 
controller 124, the corresponding data is selected and displayed again. These cells 
contain the show title and represent the area the consumer may browse through to 
view the one day program schedule or select a program that is currently being 
broadcast on a station. When a highlighted program is currently in progress the 
consumer may select that program by double clicking (or by pressing the <Enter> key) 
the program cell 123. The cells 123 are displayed with corners marking the start and 
end times. 

A program cell 123 can be selected through three different processes as 
follows: 

1 ) The user can use the mouse to click a cell and the cell will then be the selected cell; 

2) The user can scroll using the keyboard arrow keys and each arrow key press will 
select the cell the user is navigating to; or, 3) When the system timer adds a minute to 
the local clock and the first cell on the grid then becomes in the past, the new first cell 
in that row will become the selected cell. If the selected cell is not in view when 
automatic scrolling takes place, nothing will change, but the system will display the 
appropriate selected cell when it comes into view. Similarly, three different processes 
are provided for changing the viewable contents of the program cells grid: 1) The user 
may use the arrow keys to navigate and as the selected cell meets a boundary, the 
grid automatically scrolls if there is more information in the desired direction; 2) The 
user may click the scroll bars 120 and as long as there is information in the direction 
the user is scrolling, the grid will scroll; or, 3) If the system clock updates and visible 
cells become in the past, the grid will automatically scroll. 

The IPG functionality as described above is identical to that of the TV/set-top 
box environment but without the PC's windows-based features including the ability to 
minimize/resize the IPG window, the scroll bars 120 and the drop down list box 
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functionality provided by the Scheduled Day controller 124 and Quick Access 
controller 125. In addition, the PC's user-input mouse clicks would be substituted with 
STB remote controller clicks. 

When the IPG component is invoked (i.e. by clicking on the IPG icon 109 or on 
the Remote Controller's IPG button) the system manager retrieves the correct current 
date and time for the consumer's time zone, corrects all the shows times according to 
the consumer s time zone, selects the IPG data for the whole current day beginning 
with the current time, assigns the selected data to the IPG window s components and 
activates the IPG window. 

As stated above the IPG is a software application that operates in, for example, 
both a windows and set-top environment and provides a link to a client 
MPEG-1/MPEG-2 decoder and a client conditional access module. This software also 
provides the user with access to all broadcast content on the broadband multicast IP 
network as well as supporting services (i.e. subscription management). The IPG data 
delivery software component 60 is server software which provides the broadcast 
content schedules to the IPG client component software 65 based on the broadcast 
provider, customer location and customer profile. The server software 60 operates to 
extract broadcast content schedules from various existing data sources. 

A banner server 64 is server software which provides scheduled ad insertion 
into the IPG based on certain criteria such as the time of day, the broadcast provider, 
the customer location and the customer profile. A near video-on-demand (NVOD) 
server 66 provides scheduled managed delivery of pre-recorded material via an IP 
multicast network. A customer profile management system/subscription management 
software component 68 stores and tracks customer preferences, usage patterns, 
billing status, mailing addresses, client devices, service subscription, etc. It also 
provides the core data for many of the other components of the system manager 
(DTVM). A notifier and indicator software component 70 enables the system to script, 

16 
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send and display on the customer's television/set top box or computer display notices 
and messages such as notifications regarding service changes or regarding broadcast 
scheduling changes affecting programs which have been scheduled for recording, 
promotional features, telephone message caller ID and recorded messages. 

The IPG may also provide access to VOD, NVOD, VDVR, Timeless TV and TV- 
on-demand, Internet programming and video and audio content. "VOD" is an umbrella 
term referring to technologies that enable individuals to select a video (e.g. movie) 
from a static array of pre-recorded multimedia choices provided from a central server 
for viewing on a television or computer screen. The on-line applications enable 
individuals to select program content stored in a dynamic array of recorded video 
broadcasts provided from a central server for viewing on a television or a computer 
screen. The multimedia selection could, similarly, provide for games-on-demand 
whereby Nintendo™-type games may be made available for access by subscribers 
through the IPG. Alternatively, a Web user interface may be provided for selection of 
a game whereby subscribers are charged per game/time played. 

The on-demand VDVR software server 1 00 provides the user access to video 
playback using interactive DVR controls for optimal control. It includes tools for 
storing, managing and delivering real-time, full-screen video and audio content. In 
addition to tools for recording, storing, managing and delivering full screen video and 
audio content, it utilizes the core components of the system manager, including, but 
not limited to, Customer Profile Management 68, Interactive Program Guide 65, 
Consumer Self-Service 71 , Operational Services 88, Multilingual Support (not shown), 
and Channel Packaging 104. 

A conditional access system (not shown) consists of both a source and 
destination software component and is responsible for the encryption, as desired, of 
data between the source and destination to protect against unauthorized use or 
copying. 
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A consumer services application 80 enables and controls connection services, 
self-ordering services and provisioning. An automatic service function of the 
consumer services application 80 eliminates the need for the service provider (e.g. 
Telco service trucks) to go to the consumer's location to add or remove new channel 
offerings. Instead, the subscriber is provided the means to change channel/package 
information online. Consumer profiles are updated immediately to the consumer's 
STB or PC by way of IP Multicast and/or SNMP. This eliminates any need for 
equipment and/or personnel's physical presence to be dispatched to the user s home 
to connect or disconnect the appropriate channels. An administration services 
application 82 handles, inter alia, the importation of IPG data on a scheduled basis. 
Channel packaging, which enables a user to manage the user's subscription 
(including self-service), is provided by a user interface module 71 and enables the 
user to view, add and delete channels from the user's service subscription. A report 
and billing software application 84 provides integrated billing and reporting which 
enables a user (subscriber) to dynamically monitor service usage, keep track of 
service costs on a self-serve basis and pay bills. A user is able to utilize this ability to 
monitor the household's viewing history to determine, for example, the amount of 
television being viewed by children and whether the programs watched are suitable. 
A database software component 86 provides an information database of broadcast 
content unique to the broadcast distribution system provider to feed the IPG database. 
An operational services component 88 of the system manager integrates the control of 
all the broadcast delivery system components into a networked management 
framework and provides quality management functions and collects usage 
information. 

Additionally, the DTVM enables remote management of the user appliances 
including the ability to query and reset key indicators such as system health indicators 
(e.g. MPEG diagnosis), application and network status (e.g. current viewed channel, 
current NFS server), and to re-initialize a user device. This may be accomplished by, 
for example, an SNMP protocol. The DTVM also remotely informs the user, to the 
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user's set top box or computer display, that new data and/or software is available and 
should be retrieved. This may be accomplished by, for example. IP multicast and/or 
SNMP. 

The broadcast delivery system may also provide to the service provider an 
option of assigning URL's to channel numbers. A URL is an address used to enable 
an Internet browser program to find a particular Internet resource, for example. 
http://www.imagictv.com'. Using this feature a subscriber could view a URL channel 
on the IPG similar to a television or video channel. Subscribers are then able to scan 
through URL channels and select a desired URL by entering the associated numbers 
from the remote device in the same way as television or video channels are selected. 
Going through a URL channel would switch the user device (e.g. the set top box or 
PC) to a web browser and thereby access a selected web page. The broadcast 
delivery system may also provide for channel hotlinks such that while watching a 
program, or when a program is highlighted on the IPG. the user can operate a remote 
entry device to activate a transfer to a dynamic web page. Such web page could 
display, for example, information on the program, on the channel, or on the subject 
matter currently being shown. 

The DTVM software enables a subscriber to personalize channel selection, for 
example, create a list of favourite programs which the user can scan on the IPG and 
select from or have the television/set top box (or computer) automatically switch to at 
designated times. In addition, a one touch search feature may be provided to enable 
a user to specify certain searching criteria, such as program theme, by actor, by 
program/movie title, etc, and initiate one step searching to retrieve requested 
programming information from the IPG. Similarly, the user may be provided with the 
ability to view a program's video trailer from the interactive program guide when the 
user "clicks on'Vselects that program. The DTVM software may also provide an 
intelligent agent which may be set up to remind a user of an upcoming program, or 
recommend program content based on user criteria, provide gathered data from 
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outside source such as TV Guide, movie critics, etc. 

Other features provided by the DTVM include Multicast download where 
information required to boot a network device to a multicast group is constantly 
5 delivered by a network server. The DHCP server is configured to return the multicast 
address and port as parameters in a BOOTP response. The network device is 
programmed to join the multicast group and download a bootstrap program to local 
memory and boot from the local memory rather than across the network. Also, the 
system can provide a multicast file system wherein a server constantly delivers a read- 
10 only file system to a multicast group. A network device is programmed to access the 
file system by joining the multicast group and waiting until the requested file appears. 
Encryption is used for security and compression is used to minimize bandwidth. Since 
multicast UDP may lose packets, the multicast group is rejoined and holes in the files 
are filled if holes exist. 

15 

For the PC user, the DTVM includes a PC component for installation in the PC 
which, advantageously, allows the user to watch television programming on a PC 
using the normal PC hardware and without requiring special hardware such as a TV 
tuner card. The PC component utilizes the core components of the DTVM such as 

2 0 Report and Billing Services 84 (including Integrated Reporting, Integrated Billing, and 
Service Administration), Administrative Services 82 (including IPG Data Import, 
Channel Packaging and Service Administration), Consumer Services 80 (including 
Connect Services, Consumer Self-Service and Provisioning), the Interactive Program 
Guide Client (including NVOD, Live Mpeg, Notifiers and Indicators, Profile, IPG Data 

2 5 Delivery and a Banner Service), the Browser Client (including Email, the World Wide 
Web, VOD, the On-Demand products, and Self-Ordering) and the Operational 
Services 88 (including Event Export, Event Collection and Network Management). On 
the client side, the PC component provides all of its functionality in software. 
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The PC component is itself comprised of three main components: a player 
window component, a virtual remote control component and an IPG component. The 
player window component provides a resizable viewing window 1 12, as illustrated by 
Figure 8, containing three selectable objects: a channel selector 108 , a program 
5 guide icon 109 , and a remote control icon 110. The channel selector 108 is a pull 
down window that enables the user to select and retrieve an IP multicast stream 
corresponding to a specific channel. When the remote control icon 1 10 is selected a 
virtual remote controller 114 (being a window-type GUI) is opened and displayed as 
illustrated in Figure 8. When the program guide icon is selected an IPG as shown by 
10 Figure 7 appears as a separate contollable window. 

The PC component is navigated by the user using traditional windows-based 
click functions on drop down lists, together with the virtual remote control. The remote 
control design is such that, for user comfort, it represents a virtual model of the known 

15 physical hand-held remote controllers. The virtual remote controller 1 14, showing the 
basic functions available, is illustrated in Figure 9. Figure 10 shows the "options" box 
selected for the virtual controller 1 14 and the various optional functions which are 
available to the user are displayed below the "options" button. As shown by Figures 9 
and 1 0 the virtual remote controller 114 includes user-selectable features for channel 

20 up 131, channel down 132, volume control 133, power off 134, Guide (i.e. go to IPG) 
135 plus an expandable options feature 136 providing "preferences" 137 (viz. which 
directs the system manager to always hide the remote controller on start-up or to 
display the remote contoller to the left, to the right or always on top of the player 
window). TV Off 138 (which directs the system manager to turn off the player window 

2 5 but to continue to run the system manager), Hide Remote 139 (which directs the 

system manager to close the virtual remote controller display) and About 140 which 
provides particulars of the version of the system manager application which is being 
run. The DTVM's Interactive Program Guide is interactive and allows users to scroll 
up, down, forward or back through several days of programming. A further optional 

3 o function which can be provided by the PC component is to enable the subscriber to 
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store a received program in the hard drive of the PC whereby the PC would emulate a 
Personal Digital Recording device. 

The PC component is made available to the user through downloading of 
5 software from a Web-based self-service component 71 . The download software 

includes a Java Runtime Environment and Java Media Framework (being executables 
which are required by the PC component) and a PC setup program module. Once 
installed the PC component retrieves the IP address of the Application Server, the 
default language and the help desk registration number from the local config file 

10 downloaded during the install process. It then establishes a connection to the 

Application Server and retrieves the system data from a Registry file. It also retrieves 
the IP addresses and ports of the IPG data and IPG related data from the database. 
To retrieve IPG related data the PC periodically joins the IP Multicast group for the 
IPG related data for the specified IP address and port, waits for the beginning of the 

15 stream and downloads the IPG data until the end of the stream and then extracts and 
stores the program information for existing stations including schedule information on 
its local drive. The delivery system searches the server for the consumer file to 
confirm the consumer has subscribed to the service and retrieves the consumer 
specific information from the consumer file including any custom profiles the user may 

2 0 have created. 

Channel selection for the PC component is identical to that for the STB in that 
when the user selects a channel from the channel lineup, the system checks for the 
source type of the channel and, ilf it's video/audio, it gets the IP multicast address and 

2 5 port of the selected channel from the IPG Related Data object and 'tunes' into the 

channel by joining the multicast address, thereby retrieving the signal from the 
transport network rather than, as in conventional tuning systems, tuning into one of 
several signals broadcast into the home. If the source is a Web channel, the system 
clears the player window, gets the homepage URL associated with the channel, and 

3 o launches the default browser for the already retrieved URL. In the home, subscribers 
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select a channel number on the virtual remote controller. This triggers the PC 
component to issue an IGMP (Internet Group Management Protocol) request to join 
the corresponding IP multicast address. That is, the channel entry triggers the PC 
component to 'tune into' the IP multicast address where the channel can be found. To 
service the request, an IGMP-enabled network router sends channel data to the PC. 
Completing the process, the PC decodes the packetized MPEG stream into video and 
audio for display on the PC monitor. 

Optionally, as shown by Figure 1 1 , concurrent transmission of each channel via 
both MPEG-1 and MPEG-2 may be provided to allow fall back when access 
bandwidth becomes impaired. This, in effect, provides a backup system if failure 
occurs on the main transmission facility. Use of such a back-up system, based on a 
configurable algorithm, enables the system manager to recognize that there has been 
a failure to deliver a video signal and, on doing so, to switch to an alternate signal. 
This increases the level of broadcast availability in the event of a loop (e.g. xDSL) 
impairment, encoder failure, or facility/network failure. This also allows for multiple 
client devices (STBs and/or PCs) in a single home to negotiate for the best available 
signal. 

In accordance with the present invention broadcast on-demand applications, 
designated herein as "TimelessTV", "Virtual DVR (VDVR)", and "TV-on-Demand", are 
provided for integration with the broadcast delivery system. Each such on-demand 
application is based on a Network DVR (NDVR) component. End-user interfaces for 
the Virtual DVR and TimelessTV applications are patterned as a historical or non- 
linear interactive program guide (TimelessTV) or as a personal video recording library 
(Virtual DVR) and each is implemented on the system manager (DTVM). TV-on- 
Demand programs are accessed through searching and browsing interfaces. Figure 4 
shows a schematic block diagram of the delivery system in which these on-demand 
applications are integrated. As detailed below, for each of the VDVR and Timeless TV 
applications, one or more on-demand video servers 90 in the network maintain a 
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continuous recording of the IP Multicast broadcast content from a number of previous 
days (the number is application specific) for on-demand access by a subscriber (user) 
at some User-selected finite time after the program was initially shown. The stored 
data is indexed and made available to the subscriber in an easy-to-use format via the 
5 HTML-based IPG on the subscriber's television or computer monitor. The VirtualVDR 
application uses the video server 90 to provide a subscriber with all the features of a 
standard television-connected VCR/DVR machine plus random access and 
simultaneous multiple station recording functionality, plus automatic upgrading for new 
services/features. The Timeless TV application uses the same continuous recorded 

10 broadcast content to enable subscribers to select a program for on-demand viewing 

without need to view such program at the scheduled broadcast time for such program. 
For the TV-on-Demand application one or more on-demand video servers 90 in the 
network maintains a periodically updated inventory of programs provided by a 
multimedia content providers for on-demand access by a subscriber at some user- 

1 5 selected finite time. 

The on-demand applications of the present invention are comprised of the 
following three broad software components: 

1. Client, administrative, and operational software components implement the 
2 o subscriber interfaces to the on-demand applications. 

2. Administrative and operational software components implement administrative 
and operational interfaces to the on-demand video server. 

3. On-demand video server software. 

2 5 For the TimelessTV application network video servers record all or most of the 

multicast content from a selected set of broadcast sources (i.e. stations) and the 
recorded programs are made available to subscribers by extending the DTVM 
interactive program guide (IPG) to include historical IPG data. TimelessTV 
subscribers are thereby enabled to view any previously aired program, provided that 

3 o the program was recorded within the particular service window (eg, past 7 days) which 
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has been implemented by the service provider. All on-demand applications integrate 
simply and seamlessly with the DTVM IPG. 

The Virtual DVR application also uses video servers to capture all or most of 
5 the multicast content from a selected set of broadcast sources. The functional 

difference between the Virtual DVR and TimelessTV applications is that for the former 
subscribers explicitly select the broadcast programs that they want to record before or 
during the actual broadcast of the programs. The service provider maintains a 
personal video recording library for each subscriber of the Virtual DVR application and 
10 subscribers are permitted to playback recorded content only from their own library. 
From the subscriber's perspective, the basic service obtained from the Virtual DVR 
application is equivalent to the service provided by video recording using a standard 
household VCR machine connected to the television. 

15 For the TV-on-Demand application the service provider/content provider(s) 

determine the programming to be made available to subscribers and the duration for 
which such material is to be made available for playback. Content providers use the 
service provider's multicast transport network to upload a fresh set of programming 
and advertising content on a periodic basis (e.g. daily). This content is made available 

20 to subscribers for playback on the next service day and is retained by the service 
provider for the duration of a designated service cycle. 

The VDVR on-demand application user interfaces enable subscribers to record 
a program from the IPG, while watching a program or from a main menu portal (see 

2 5 Figure 12 in which each of these options is illustrated, wherein a "Hockey Night" 

program is selected from an IPG (a) for recording and thereby added to a Schedule 
List window (d) displayed to the user, and also showing a recording selection from a 
program display (b) showing that hockey game and a selection of the Schedule List 
window directly from a main menu (c)). The Schedule List window displays a listing of 

3 o the programs which have been selected for recording and the program just selected is 
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shown in highlighted form. From the Schedule List (d) the subscriber may select a Set 
VCR or Play List window, the Set VCR (Set to Record) window being shown in Figure 
13 and the Play List window being shown in Figure 14 (and, as shown, the Play List 
window also allows the user to select the Set VCR option). Information pertaining to a 
program selected for recording is obtained by highlighting and selecting the program 
from the Schedule List window whereby a Program Info window is displayed as shown 
in Figure 15. As shown, using the Program Info window the user is able to direct the 
recording record to Record Once (for one time recording of the program), Record 
Always (for setting the system to always record that particular program in future when 
and if it is broadcast on a specified channel at a specified time) or Extend Time (for 
setting the system to automatically extend the recording time for the program so that a 
late running of the program, such a hockey game, will also be recorded). The Set to 
Record window of Figure 13 provides the subscriber (user) with an alternative means 
of scheduling a program for recording whereby the user selects the channel, the date 
and the time to record a program. This screen is accessible from either the Schedule 
List, the Play List or the main menu portal. A second Program Info window as shown 
in Figure 16 is displayed instead of that of Figure 15 when a recording directive has 
already been selected for a selected program and, as shown, this user interface 
window enables the user to direct that the system either play or delete the program. It 
is to be noted that the designations "Virtual VCR" and "VCR" appearing in Figures 12- 
16 refer equally to the designations "Virtual DVR" and "DVR" used herein, the latter 
being used herein only because DVRs represent more current technology and are 
tending to replace VCR. 

The central storage device (being remote from the subscribers) on which the 
recorded program is stored, and its associated software, record only one copy of a 
subscriber-tagged program for access by multiple users later. Multiple channels may 
be recorded at one time for later, on-demand play by the user. Further, the recording 
is performed by the system on a "just in time" basis whereby the user is able to direct 
a recording after the program broadcast has commenced, up to the time the broadcast 
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has finished, because the system automatically captures all broadcasts and decides 
upon those which are to be stored to satisfy user-entered recording directives only 
after the broadcasting of the program has been completed. 

When a program is selected for play the VDVR component provides an HTML 
GUI providing VCR/DVR- like control functions of Play, FastForward, Pause and 
Rewind, and Stop. Optionally, the system may be configured to allow a subscriber to 
record pay-per-view programs once they have purchased the pay-per-view program 
through the DTVM. Also optionally, on-screen multilingual support may be provided 
by the DTVM and the service provider may configure an Online Help function on a 
customized basis. 

A Web interface may, optionally, be provided to enable subscribers to access 
through the Internet, using a password or other secure access means, the VDVR 
component user interfaces (e.g. per Figures 12-16) as well as the DTVM IPG 
component. Using such an interface a subscriber is able to select programs for 
recording from any place where the subscriber has access to a Web browser and the 
Internet. 

Security is established by referencing the client IP address against the DTVM 
database 86. The service provider is able to manage the recordable stations by 
packaging such station channels. That is, by referencing the DTVM database, 
recorded channels can be made a subset of the channels subscribed to by the 
subscriber. Advantageously, the subscriber is able to remotely activate or deactivate 
the Virtual DVR system through their TV screen, or monitor, without third party 
intervention. 

The Virtual DVR component framework is represented at a high level by the 
schematic block diagram of Figure 1 7. The Virtual DVR component model uses the 
servlet model as the basis for all user interactions, including subscriber, operator, and 
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administrator interactions. In this model, the VirtualDVR servlet (server)106 provides 
the external interface to users interacting with the VirtualDVR component 100 by 
serving up HTML pages in response to user requests 101, 102 and 103 and process 
user directives encoded in those requests. Additionally, the VirtualDVR servlet 
inherits from its framework the following core components that permit it to be 
recognised and to operate as an integrated component of the DTVM: 

• Logging 

• Internationalization 

• Security 

• Error handling 

• Service configuration 

The VirtualDVR servlet 106 provides all control functions for the Virtual DVR 
application and acts as the first point of contact between VirtualDVR users and the 
component. This includes parsing request URLs to determine the nature of each 
request, updating the application data model based on the settings of parameters 
included in the request, and handing the request off to an appropriate JSP™ (Java 
Server Page™) to generate the HTML to be included in the response. Additionally, 
the servlet creates and maintains the VirtualDVR application context and makes this 
available to VirtualDVR JSPs through exported interfaces. 

VirtualDVR JSPs generate formatted HTML pages using application and user 
data extracted from the supporting data model and from the VirtualDVR application 
context. There is one JSP for every frame on every distinct user screen, and each 
JSP is associated with a request handler that the servlet calls to prepare the data for 
the dynamic content of the JSP and obtain a request dispatcher that the servlet uses 
to invoke the JSP. 

All servlet and request handler access to subscriber and system data relating to 
the VirtualDVR application is effected through interfaces exposed in the VirtualDVR 
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component 100. The request handler prepares the data required by its JSP and 
associates the prepared data with the client request to make it available to the JSP. 
The actual VirtualDVR data is distributed over several components of the DTVM data 
model, and the request handlers and VirtualDVR component 100 interact with a core 
Data Acquisition Component (DAC) 107 and other core components as required. 

When the VirtualDVR servlet is initialised it first loads its configuration files. 
This is a two-step process. First, a default application configuration file that is 
maintained for the application framework is loaded into the servlet context. This 
framework configuration file contains configurable settings that are global to all 
servlets that are based on the application framework and contains only one setting 
that relates to the VirtualVCR servlet. That setting refers to a fully qualified path to a 
VirtualDVR configuration file containing configurable settings unique to the VirtualDVR 
application. 

The settings contained in the framework and VirtualDVR configuration files are then 
made available to VirtualDVR request handlers and to the VirtualDVR application 
component through a VirtualVCR servlet context object. The VirtualDVR servlet 
context extends the generic servlet context defined by the application framework, so 
the methods defined for the generic servlet context will be inherited and exposed by 
the VirtualDVR servlet context. Once the configuration files have been loaded into the 
servlet context, the servlet creates and initialises an instance of the VirtualDVR 
application component and provides it with a reference to the VirtualDVR servlet 
context. 

A section of the VirtualDVR configuration file specifies two lists of fully qualified 
Java class names. One of these lists, the request map. specifies the set of request 
handlers defined for the application. The other list, the command map. specifies the 
set of command handlers defined for the application. When the servlet loads these 
lists it creates a single instance of each request or command handler and associates it 
with its unqualified class name, which is used in client URLs to refer to the request or 
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command handler. For each request or command handler, the servlet provides 
references to the VirtualDVR sen/let context and application component. The 
initialisation of the VirtualDVR servlet is complete when the application component 
and all of the request and command handlers have been created and initialised. At 
this point, the servlet is ready to begin its service cycle. 

Each client request submitted to the servlet is encoded as a URL comprised of 
a reference to the VirtualDVR servlet on the host Web server and a list of parameters 
and parameter values, characterized according two parameter sets - request 
parameters and, optionally, command parameters. Command parameters consist of 
an command identifier, corresponding to a particular action that is to be performed 
before processing the request parameters, and additional parameters that may be 
defined for a particular command. Typically, these actions involve modifying the 
underlying data model but may also be directed to modifying some aspect of the 
servlet context. In any case, the servlet uses the command identifier to determine 
which additional command parameters to pull out of the client URL to dispatch the 
command and pre-processed parameters to an appropriate command handler. Not all 
client requests must contain command parameters so it is acceptable for a client 
request to contain no command directive and associated parameters. 

Request parameters consist of a request identifier and a list of parameters that 
are defined for the particular request handler. The servlet uses the request identifier 
to determine which additional request parameters to pull out of the client URL and 
route the request and pre-processed parameters to an appropriate request handler. 
The request handler is invoked to prepare the dynamic data required by the 
associated JSP and returns a request dispatcher that is used by the servlet to invoke 
the associated JSP, which in turn generates the HTML for the user page or frame and 
returns it to the client for display on the client screen. This completes the processing of 
the client URL. 
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Each Web client request that is forwarded to the servlet is handled on a 
separate thread. The servlet expects all persistent state information to be maintained 
within the servlet context and application component and all request and command 
handlers to be stateless and fully re-entrant. All (and only) the classes that comprise 
the servlet context and application component will be synchronised to ensure thread 
safety. 

The VirtualDVR context is comprised of the union of the generic servlet context 
(derived from the application framework), which provides support for multilingual text 
and graphics, logging, error handling, and security, and additional context that is 
specific to VirtualDVR. The specific context includes access to VirtualDVR 
configurable items defined in the VirtualDVR configuration file and helper functions to 
support the generation of well-formed VirtualDVR URLs including request and 
command parameters. 

All request and command handlers are created and initialised during servlet 
initialisation. When the servlet creates a request or command handler, it passes 
references to the servlet context and the application component to the handler. Each 
handler stores these references and creates and initialises any class data members 
that it requires. Importantly, request and command handlers are discouraged from 
creating any mutable class or instance data members since they are considered by 
the servlet to be available for concurrent use by multiple threads. 

The names of request and command handlers are encoded in VirtualDVR 
servlet URLs and used as a basis for routing client requests to specific request and 
command handlers. Each request handler is aware of the location of its associated 
JSP and knows which parameters are required to satisfy the request: The request 
handler undertakes to parse these parameters out of client URLs, prepare the 
dynamic data required by its JSP, and return to the servlet a request dispatcher that 
the servlet can use to invoke the JSP. 
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A Network DVR (NDVR) application is central to each of the on-dernand 
applications. The NDVR captures the broadcast video content in real-time by 
selecting a number (e.g. up to 100) of concurrent multicast stations according to a 
recording schedule determined by the service-provider. The granularity of the 
recording schedule is very course (e.g. allocated in half-hour or hour segments) and 
this allows the NDVR to capture large blocks of IP multicast content without reference 
to the particular programming schedule of recorded stations. In the preferred 
embodiment the recording schedule covers an entire week of programming and 
recording is enabled during high-demand times of each day. Since the daily recording 
pattern is the same, the schedule for a single day is set up and repeated on each day. 
The period of time between cycles of the recording schedule is referred to herein as 
the "scheduling window". The number of days that recorded content is retained and 
available for playback is referred to herein as the "service window". 

An appropriate recording schedule for the NDVR is multistation recording on a 
24 hours/day over a 7-day cyclic scheduling window or 12 hours/day over a 1-day 
scheduling window. The NDVR recording schedule is not dependent on the particular 
programming schedules of the recorded stations but instead is designed to capture 
everything over a service provider -defined scheduling window (or, for example, could 
be designed to capture content aired during the most popular times of day for the 
most popular stations). The mapping from specific programming events to recorded 
media is supported by l-frame indices in playlists maintained by the NDVR and 
appropriate application interfaces. 

The coupling between the NDVR and end-user interface for each of the on- 
demand applications is designed to be loose because the factors which will enable 
future improvements for the NDVR (i.e. video server hardware and software 
improvements) independent from and unrelated to the factors that will determine the 
specific implementations and improvements of the particular on-demand applications 
(i.e. legal and regulatory issues, market forces). 
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The preferred embodiment of the NDVR application is based on nCube 
MediaCube 4 video server hardware and OVS 4.0 software and utilizes Optibase 
encoders. A master NDVR installation is used at the head-end of the broadcast 
delivery system and a number of edge NDVR installations (preferably in the ratio of 
5 1:5) are provided at the edge of the service provider network, the master NDVR 

capable of recording 50-100 stations and each edge NDVR capable of recording 10- 
20 stations. The service window designated for the master NDVR is 168 hours (24 
hours x 7days) and for each edge NDVR is 36 hours (12 hours x 3 days). The 
minimum disk storage capacity required of the master NDVR is 10-20 TB and for each 

1 o edge NDVR it is 400-800 GB and the number of outbound streams of the master 

NDVR is at least 2000-4000 and for each edge NDVR is 500-1000 so as to provide for 
an aggregate number of 4500-9000. 

The networked master and edge servers run identical software loads but 
1 5 operate according to different recording schedules and their supporting hardware 

differs. This configuration provides scalability so that the on-demand application can 
scale seamlessly from low loads (eg, 30 stations, 12 hours/day, 3 day cycle) to high 
loads (100 stations. 24 hours/day, 7-day cycle). The master NDVR is deployed at the 
service provider's head end to capture all of the content that is to be made available to 

2 o Virtual DVR subscribers for the full duration of the service window. Additionally, for the 

preferred embodiment, edge servers are deployed within locally distributed central 
offices and these are scheduled to record a high demand subset of the content 
recorded by the master server and to retain it for a shorter service period than the 
service period of the master server. A high hit rate on the edge servers may be 

2 5 obtained by tuning their recording schedules on the basis of ratings and other data, 

even if a shorter retention period is used for them. Additionally, for the preferred 
embodiment, edge servers are deployed within locally distributed central offices and 
these are scheduled to record a high demand subset of the content recorded by the 
master server and to retain it for a shorter service period than the service period of the 

3 o master server (i.e. the edge server does not capture and cache any content from the 
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master server). The edge server recording schedules are designed so that, on 
average, 80% of client playback requests can be satisfied by the closest edge server; 
the other 20% of requests that miss the edge servers will be satisfied from the master 
server. 

All NDVR content is recorded by tuning into real-time IP multicasts originating 
from the MPEG1 encoders at the service provider head end and are recorded in 
identical formats (2 Mbps fixed rate). On recording the NDVR must tune into an IP 
multicast stream and record content from the stream on a scheduled basis and/or 
under software control. The recording scheduling interface provided by the video 
server software may be based on scheduling tables maintained in an associated 
database or on software APIs that directly control content acquisition in real time. In 
either case, it provides the following controllable parameters for each multicast 
station: 

• multicast group IP address and port 

• record in point - record content to include first l-frame in stream following this time 
(wall clock time reference) and multicast must be tuned in in advance to enable this 

• record out point ~ recording will stop at or shortly after this time (recorded content 
may be slightly longer, but must include all of the content from the in point up to but 
not necessarily including the out point) 

• segment size — length of time (in milliseconds) to be recorded into each file 
segment 

• file segment name prefix — used to generate sequential filenames for the file 
segments that constitute the recording 

For the on-demand application embodiment described herein the broadcast 
sources do not contain embedded service information (SI) and, consequently, video 
server content creation time stamps are used to resolve mappings from IPG data onto 
recorded content. Alternatively, however, if service information were to be provided in 
the digital streams that are transcoded at the service provider head end it would be 
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possible to arrange for the upstream decoder to pass some of this information along 
for the downstream encoder to insert into the multicast stream. This would allow for 
precise mapping of program boundaries on the basis of current IPG data and, if the SI 
information could be used to trigger recording, it would also enable precision recording 
5 (i.e. the start/stop for recording would occur on program boundaries and these 

boundaries would be marked within recorded content that spans program boundaries). 

Each NDVR application (both master and edge) provides fully automated, best- 
effort recording of all scheduled recording blocks, concurrently for multiple sources as 

1 o required. Additionally, each NDVR enables fully automated recovery of storage space 

for all recorded content as it ages out of the service window. 

Each NDVR application utilizes a cyclic recording process that has a period 
equal to the duration of the scheduling window but which is enabled (recording) only 
1.5 within the boundaries of scheduled recording blocks set up for the IP multicast source. 
The recorded content for each block is distributed over several sequential files of 
equal length (for example, record a 12-hour block into 24 files of 30 minutes duration) 
and a playlist is created to map this distribution for playback purposes. The method of 
cyclic recording, whereby content is recorded to a ring of files of equal length, has a 

2 o number of advantages. First, this method enables the video server to record 

continuously by wrapping around and overwriting the first (oldest) file segment with 
new media when the last (most recent) segment becomes full, thereby automating the 
process of storage recycling. Second, the consistent use of equal size files for all 
recording helps to alleviate the problem of disk fragmentation, which can become 

2 5 severe when the rate of storage recycling is high. 

Just before a new scheduled recording block is started, the NDVR creates a 
new playlist and copies the current scheduled recording block and service window 
duration into the playlist for future reference. It then allocates an empty content file to 

3 o record into, joins the multicast source stream, and co-ordinates the start of the 
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recording on the new file. When the file is filled, the source stream is seamlessly cut 
over to a new, empty content file. When the scheduled recording block is finished the 
multicast receiver leaves the stream, closes the last content file, and saves the 
playlist. This is repeated for the all recording blocks of the scheduling window and 
then the whole cycle is repeated successive scheduling windows. 

The NDVR also operates according to a cyclic service process having a period 
equal the duration of the service window. The oldest recorded playlists are tracked 
and their content files are recovered (i.e. for re-use) as they age out of the service 
window. This is done in real time, so that playlists that are aging out of the service 
window lose content files from one end while subscribers continue to play unexpired 
content at the other end. Playlists are deleted after all of their associated content files 
have been recovered. This means of handling the storage media achieves an 
automatic recycling of all recorded content and playlists after the completion of each 
cycle of the service window with a minimization of disk fragmentation. 

For the VirtualDVR application, a greater recovery rate of content files is 
achieved by monitoring the scheduled recording blocks and identifying those that do 
not contain programs that have been marked for recording by at least one subscriber, 
whereby those which have not been marked by a subscriber are recovered. 
Preferably, all scheduled recording blocks are recorded without regard to whether or 
not any subscriber has previously marked a program within the block for recording as 
this enables subscribers to select (mark) a program for recording at any point up to the 
end of the scheduled program broadcast. After that point, however, it is selected that 
subscribers of the VirtualDVR application cannot mark a program for recording and, 
on this basis, a map of subscriber recording requests is constructed for each recording 
block at the end of that scheduled recording block. The complement of this map is 
used to identify and immediately recover those content files that do not contain 
subscriber-designated recordings. 
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A "best-effort" recording method is applied by the NDVR application. Each 
scheduled record block is demarcated with real-time Coordinated Universal Time 
(UTC) record in and out points with millisecond resolutions. In the absence of 
embedded SI in the multicast source stream, these time references are interpreted 
against the real-time clock of the video server and although this involves a margin of 
error due to the unknown difference between the real-time clocks of the source 
(broadcaster) and sink (video server) the effect is insignificant. 

The video server makes a best effort to capture the media between the record 
in and out points and creates a playlist to map the locations of successfully recorded 
frame sequences with respect to the realtime clock. Since the source signal may drop 
out occasionally due to IP multicast packet loss or transient faults at the source 
encoder, each run of successfully recorded frames must be correctly located in real 
time so that its relative position in the playlist can be fixed. Once the real-time position 
of the head of the playlist is fixed, this is done accurately using the program clock 
reference (PCR) embedded in the source MPEG transport stream, taking the PCR 
value of the head of the playlist as a basis reference point. This use of PCR values 
recovered from the source signal to correctly locate frame positions relative to the 
head of the playlist enables frame-accurate random access to any GOP within a 
recorded block, irrespective of any drop-outs that may have occurred during the 
recording process. This feature enables accurate translation between user playback 
requests, which are expressed using UTC in and out points within the recorded block, 
and the file locations of the l-frames at the playback request in and out points. It also 
forms the basis for a playback integrity metric, such as the percentage of frames 
recorded successfully between the playback request in and out points. 

Recording from multicasts requires that content metadata be generated in real 
time as content is recorded, and this will involve a high system overhead as the entire 
MPEG stream must be parsed to recover the PCR, l-frame file location offsets (and, if 
present, any SI information). Also, software RAID (Redundant Array of Inexpensive 
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Disks) incurs a high system overhead and cannot be effectively pipelined with MPEG 
parsing. Therefore, the benefits of RAID must be weighed against the costs, in terms 
of processing overhead (software RAID), additional expense (hardware RAID), and 
the impact of individual media storage drive failures which will largely depend upon the 
manner in which contiguous content is distributed across drives. If recorded content 
files corresponding to a single scheduled recording block tend to be concentrated 
within drives, the failure of any single drive would tend to affect only a few programs 
on a single station. Accordingly, the service provider may elect not to attempt RAID 
recovery of the drive contents in these cases if drive failure is a relatively infrequent 
event. 

For the on-demand applications, the primary functional requirement of the video 
server on the playback side is to provide playback of whole programs. A request for 
playback of a given program is based on IPG data that determines the station (source) 
that the program was aired on, the air date, and the duration of the program. When 
this information is mapped to the physical media file, it may be the case that content is 
distributed across several media files and that there are several discontinuities 
(dropouts) in the recorded program material owing to unreliable transport and encoder 
restarts. The use of the playlist for each scheduled recording block makes the actual 
distribution of the content across the video server's media store inconsequential. The 
video server software creates a master playlist mapping the distribution of successfully 
recorded media and of dropouts over the files that comprise the scheduled recording 
block. This playlist is used as the point of reference for playback purposes for all of 
the on-applications, as described below. The duration of the playlist matches exactly 
the duration of the recording block as scheduled, with any dropouts that may be 
present being represented by pointing to a proxy clip that can be played in a loop to fill 
the duration of each dropout. 

In the absence of SI information marking the positions of individual programs 
within the playlist, the problem of locating program boundaries is solved on the basis 
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of IPG and recording schedule data and this involves a margin of error. The method 
applied by the NDVR application for resolving a subscriber request to play a particular 
program (identified by station, air date, and duration) is as follows: 

1 . Using the station ID and air date, determine which recording playlist contains 
the program and verify the entire duration of the program is contained within the 
playable region of the playlist (ie, the region within the service window); 

2. Subtract the program air date from the air date for the start of the recording 
block to obtain an offset into the master playlist for the recording block 
corresponding to the start of the program (in point); 

3. Add the duration of the program to the in point to obtain an out point for the 
program; 

4. Determine the percentage of the program that was successfully recorded (this 
can be done on the basis of the information in the playlist), to be used as a 
measure of the integrity of the recorded program; 

5. Encode the playlist ID, the in and out points, and the integrity metric for the 
program as a content locator URL and return this to the subscriber. 

(Note: If SI were present in the source stream on which program start markers within 
the master playlist could be based, a more accurate determination of program in and 
out points within the master playlist would be possible but the foregoing steps 1 , 4, 
and 5 would remain the same.) 

6. In the master playlist, locate the program start marker closest to the program air 
date and the offset to the next sequential program start marker or end of playlist 
and verify that this matches the duration of the program to within a few minutes; 
and, 

7. Using the program markers located in the preceding step, obtain in and out 
points in the playlist. 

(Note: In either case, the client playback device (i.e. set top box or computer) IP 
address is recorded and stored on the NDVR server. When the client playback 
request is subsequently received by the NDVR, the device IP address can be 
recovered from the session information and used to validate the request.) 
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A playlist can be used for playback only over regions that are within the service 
window, so that playback requests received for a playlist are granted only if the 
requested in point is still within the service window when the request is received. It 
may be selected to set a threshold some time in advance of the trailing edge of the 
5 service window and block the generation of content locator URLs with in points falling 
below the threshold so as to facilitate a recycling of the content associated with earlier 
portions of the playlist as it leaves the service window. Once the out point of a playlist 
leaves the service window it is deleted. 

io Figure 17 details the administration and operations processes on the on- 

demand applications. The service administrator configures the storage options 113 
determining the number of days that recorded content will be maintained on the 
server, that is, the duration of the service window or archive time frame. The service 
administrator configures the Virtual DVR feature parameters 1 14, namely, the 

1 5 parameters for the delivery of the Virtual DVR feature to the service provider's 

subscriber base. These parameters include recording options to be made available to 
subscribers (record always, autoreplace, permitted playback controls). 

The service administrator defines and modifies services 115 that will be made 
2 o available to a subscriber base and defines the type and name or description of the 
service. The service provider may define and change packages in accordance with 
marketing factors. Packages may consists of stations and/or services. Packages that 
include services, may be configured to include details for the service 116. For 
instance, for a package containing the Virtual DVR service, the service administrator 
is must provide the number of recording slots available (the number of recording 
schedule entries) and the retention time (the length of time that recording will be 
available to a consumer). The service administrator is able to obtain service usage 
and capacity reports 117 pertaining to the Virtual DVR service. The service 
administrator also creates, modifies and deletes recording tasks within a specific 
o recording schedule 118. Each recording schedule, and its corresponding recording 
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tasks, are for a specific video server or group of video servers. Recording tasks can 
be a single occurrence or be recurring. All recording tasks have a corresponding 
station that is retrieved from the current IPG in DTVM. Recording tasks are 
time/station based and are independent of shows. There can be an unlimited number 
of recording tasks configured for a specific server. Recording tasks cannot overlap 
with a recording task for a specific station. Recording tasks can be for a maximum of 
24 hours in length but can recur daily to create a continuous recording of a specific 
station. From an operations standpoint a video servers recording schedule can be 
modified 119. The system converts each recording task into one or more schedule 
recordings. Single recording tasks will create a single schedule recording. Recurring 
recording tasks create multiple schedule recordings. To start a record 120, the 
system clock must be greater than or equal to the start time of the schedule recording. 
The system requests the video server to begin recording a specific station for a 
specific duration. The record request requires a start time so that the corresponding 
content can be referenced via a wall clock time. Recording requests only know start 
time duration and station. There is no concept of programs, only a wall-clock time. 
Each recording request requires a unique ID for future recovery. Where a video 
server is being shut down the record component is cancelled or suspended 121 . The 
system requests that the video server suspend or terminate for a specific recording 
session previously initiated by the start record component 120. This occurs typically 
for maintenance purposes and provides a means to safely terminate or suspend any 
file creation activities. The cancel request is immediate and uses the unique ID 
generated by the start record component 120. When the video server restarts, the 
system requests that the video server resume normal activities for a specific recording 
session previously suspended by the cancel/suspend record component 121. The 
resume request component 122 is immediate and uses the unique ID generated by 
the start record component 120. 

Expired content may be removed when the system clock is equal to the start time of 
the scheduled process. Content storage is incrementally recovered by deleting 
expired content. The expiry date of content is determined by the date the content was 
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recorded and the storage options specified by the sen/ice administrator. Expired 
content and all references to that content (eg metadata) are deleted by the remove 
expired content component 123. Unreferenced content may be removed when the 
system clock is equal to the start time of a scheduled process whereby content 
storage is incrementally recovered by deleting unreferenced recorded content. 
Content is unreferenced if it contains programs that have not been selected for 
recording by any VirtualDVR subscribers. Since recording requests are honored only 
before or during the broadcast of the program, the determination of whether or not it 
has been requested can be made as soon as the program ends. The DTVM IPG and 
subscriber scheduled recording data are periodically reviewed to locate programs that 
have not been requested for recording and their content is selectively deleted by a 
remove unreferenced content component 124. 

From a client perspective, a subscriber recording interface is provided to the 
subscriber and is embodied in the existing DTVM IPG whereby recording is initiated 
by a point and click on the monitor. Alternatively, a custom search function may be 
provided to allow the subscriber to create an IPG containing only selected 
programming as determined by parameters input by the subscriber. 

Appendix B hereto sets out the requirements of the video server hardware and 
software which supports the Network DVR (NDVR). 

The terms application, algorithm, component and module herein are used 
interchangeably and refer to any set of computer-readable instructions or commands 
such as in the form of software, without limitation to any specific language, 
architecture, size, location or means of operation of the same. The terms subscriber, 
consumer and customer are also used interchangeably herein to refer to the PC/STB 
user of the broadcast delivery system. 

It is to be understood that the specific elements of the on-demand system and 
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method described herein are not intended to limit the invention defined by the 
appended claims. From the teachings provided herein the invention could be 
implemented and embodied in any number of alternative computer program 
embodiments by persons skilled in the art without departing from the claimed 
5 invention. 
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Appendix A: Glossary 

BootP Refers to Bootstrap Protocol which is an Internet protocol that enables a 
diskless workstation to discover its own IP address, the IP address of a BOOTP server 
5 on the network, and a file to be loaded into memory to boot the machine. This enables 
the workstation to boot without requiring a hard or floppy disk drive. 

Daemon A process that runs in the background and performs a specified operation at 
predefined times or in response to certain events. The term daemon is a UNIX term, 
io though many other operating systems provide support for daemons. 

Data Provider For the subject matter herein described, a company that provides 
detailed information about television programs, including station information, show 
titles, scheduled air times, etc. 

15 

DHCP Dynamic Host Configuration Protocol. A protocol for assigning dynamic IP 
addresses to devices on a network. With dynamic addressing, a device can have a 
different IP address every time it connects to the network. In some systems, the 
device's IP address can even change while it is still connected. DHCP also supports a 
2 o mix of static and dynamic IP addresses. Dynamic addressing simplifies network 

administration because the software keeps track of IP addresses rather than requiring 
an administrator to manage the task. This means that a new computer can be added 
to a network without the hassle of manually assigning it a unique IP address. Many 
ISPs use dynamic IP addressing for dial-up users. 

25 

Domain A group of computers and devices on a network that are administered as a 
unit with common rules and procedures. Within the Internet, domains are defined by 
the Internet Protocol (IP) address. All devices sharing a common part of the IP 
address are said to be in the same domain. 

30 
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DNS Domain Name System. An Internet service that translates domain names into IP 
addresses. For example, a DNS server might translate the domain name 
"www.example.com" into the IP address 198.105.232.4. 

DSLAM Digital Subscriber Line Access Multiplexer. A technology that concentrates 
traffic in xDSL implementations through a process of TDM (time division multiplexing) 
at the Telco's central office (CO) or remote line shelf. 

HTTP Hypertext Transfer Protocol. The underlying protocol used by the World Wide 
Web. HTTP defines how messages are formatted and transmitted, and what actions 
Web servers and browsers should take in response to various commands. For 
example, when you enter a URL in your browser, this actually sends an HTTP 
command to the Web server directing it to fetch and transmit the requested Web page. 

IGMP Internet Group Management Protocol. Defined in RFC 1 1 12 as the Internet 
standard for IP multicasting. IGMP establishes host memberships in particular 
multicast groups on a single network. The mechanisms of the protocol allow a host to 
inform its local router, using Host Membership Reports, that it wants to receive 
messages addressed to a specific multicast group. All hosts conforming to level 2 of 
the IP multicasting specification require IGMP. 

IP address An identifier for a computer or device on a TCP/IP network. Networks that 
use the TCP/IP protocol route messages based on the IP address of the destination. 
The format of an IP address is a 32-bit numeric address written as four numbers 
separated by periods. Each number can be zero to 255. For example, 1. 160.10.240 
can be an IP address. 

IP Multicast Sending out data to distributed servers on the MBone (Multicast 
Backbone). For large amounts of data, IP Multicast is more efficient than normal 
Internet transmissions because the server can broadcast a message to many 
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recipients simultaneously. Unlike traditional Internet traffic that requires separate 
connections for each source - destination pair, IP Multicasting allows many recipients 
to share the same source. This means that just one set of packets is transmitted for 
all the destinations. 

5 

JDBC Java Database Connectivity. A Java API (Application Interface) that enables 
Java programs to execute SQL statements. This allows Java programs to interact 
with any SQL-compliant database. Since nearly all relational database management 
systems support SQL, and because Java itself runs on most platforms, JDBC makes it 
io possible to write a single database application that can run on different platforms and 
interact with different database management systems. 

Macrovision An anti-taping process that protects original material from video piracy. 
For example, a viewer cannot record a pay-per-view movie if Macrovision protection is 
15 in place. 

MAC address Media Access Control address. A hardware address that uniquely 
identifies each node of a network. In IEEE 802 networks, the Data Link Control (DLC) 
layer of the OSI Reference Model is divided into two sublayers: the Logical Link 
2 0 Control (LLC) layer and the Media Access Control (MAC) layer. The MAC layer 
interfaces directly with the network media. Consequently, each different type of 
network media requires a different MAC layer. 

MIB Management Information Base. A database of objects that a network 

2 5 management system can monitor. SNMP uses a standardized MIB format that allows 

any SNMP tool to monitor any device defined by a MIB. 

MPEG Moving Picture Experts Group. A family of digital video compression standards 
and file formats. MPEG generally produces better-quality video than competing 

3 o formats, such as Video for Windows, Indeo and QuickTime. MPEG files can be 
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decoded by special hardware or by software. MPEG achieves a high compression 
rate by storing only the changes from one frame to another, instead of each entire 
frame. The video information is then encoded using a technique called DCT. MPEG 
uses a type of lossy compression, since some data is removed but the diminishment 
of data is generally imperceptible to the human eye. There are two major MPEG 
standards: MPEG-I and MPEG-2. Common implementations of the MPEG- I standard 
provide a video resolution of 352-by-240 at 30 frames per second (fps). This 
produces video quality slightly below the quality of conventional VCR videos. A newer 
standard, MPEG-2. offers resolutions of 720x480 and 1280x720 at 60 fps, with full 
CD-quality audio. This is sufficient for all the major TV standards, including NTSC, 
and even HDTV. MPEG-2 is used by DVD-ROMs. MPEG-2 can compress a two hour 
video into a few gigabytes. Suggested reading: MPEG Video Compression Standard, 
ISBN 0-412-08771 -5; and, Digital Video: An Introduction To MPEG-2, ISBN 0-412- 
08411-2. 

NAT Network Address Translation. An Internet standard that enables a local-area 
network (LAN) to use one set of IP addresses for internal traffic and a second set of 
addresses for external traffic. A NAT box located where the LAN meets the Internet 
makes all necessary IP address translations. NATs serve two main purposes: They 
provide a type of firewall by hiding internal IP addresses and they enable a company 
to use more internal IP addresses. Since they're only used internally, there's no 
possibility of conflict with IP addresses used by other companies and organizations. 

NFS Network File System. An open architecture operating system designed by Sun 
Microsystems that allows all network users to access shared files stored on computers 
of different types. NFS provides access to shared files through an interface called the 
Virtual File System (VFS) that runs on top of TCP/IP. Users can manipulate shared 
files as if they were stored locally on the user's own hard disk. With NFS, computers 
connected to a network operate as clients while accessing remote files, and as 
servers while providing remote users access to local shared files. The NFS standards 
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are publicly available and widely used. Because the set-top box referenced herein 
has no internal hard drive, it remotely accesses an NFS server to load its operating 
system, software, and preferences. 

5 

PDU Protocol Data Unit. An OS I (Open Systems Interconnection) term that means 
"packet". A PDU is a data object exchanged by protocol machines (entities) within a 
given layer. PDUs consist of both data and control (protocol) information that allows 
the two to coordinate their interactions. 

10 

RFC Request for Comment. A series of notes about the TCP/IP standards, 
procedures, and specifications. Anyone can submit an RFC. Eventually, if it gains 
enough interest, it may evolve into an Internet standard. Each RFC is designated by 
an RFC number. 

15 

RMI Remote Method Invocation. A set of protocols being developed by Sun's 
JavaSoft division that enables Java objects to communicate remotely with other Java 
objects. 

2 o RPC Remote procedure call. A type of protocol that allows a program on one 

computer to execute a program on a server computer. Using RPC, a system 
developer need not develop specific procedures for the server. The client program 
sends a message to the server with appropriate arguments and the server returns a 
message containing the results of the program executed. 

25 

Servlet An applet that runs on a server. The term usually refers to a Java applet that 
runs within a web server environment. This is analogous to a Java applet that runs 
within a Web browser environment. Java servlets are becoming increasingly popular 
as an alternative to CGI programs. The biggest difference between the two is that a 

3 0 Java applet is persistent. This means that once it is started, it stays in memory and 
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can fulfill multiple requests. In contrast, a CGI program disappears once it has fulfilled 
a request. The persistence of Java applets makes them faster because there's no 
wasted time in setting up and tearing down the process. 

SNMP Simple Network Management Protocol. A set of protocols for managing 
complex networks. SNMP works by sending messages, called protocol data units 
(PDUs). to different parts of a network. SNMP-compliant devices, called agents, store 
data about themselves in Management Information Bases (MIBs) and return this data 
to the SNMP requesters. 

Time Division Multiplexing A technique for transmitting a number of separate data, 
voice and/or video signals simultaneously over one communications medium by 
quickly interleaving a piece of each signal one after another. 

TCP/IP Transmission Control Protocol/Internet Protocol. The suite of communications 
protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the 
two main ones being TCP and IP. TCP/IP is built into the UNIX operating system and 
is used by the Internet, making it the de facto standard for transmitting data over 
networks. 

UDP User Datagram Protocol. A connectionless protocol that, like TCP. runs on top 
of IP networks. Unlike TCP/IP UDP/IP provides very few error recovery services, 
offering instead a direct way to send and receive datagrams over an IP network. It's 
used primarily for broadcasting messages over a network. The system manager 
described herein uses the UDP protocol for the RPC server and this was chosen 
instead of TCP because TCP allows a limited number of set-top box connections 
through the RPC server. If the RPC server went down, the set-top boxes could not 
reconnect. 
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URL Universal Resource Locator. An address format used by a Web browser for 
locating an Internet resource. 

xDSL x Digital Subscriber Line. Generic term for all types of digital subscriber lines, 
5 including ADSL (Asymmetrical DSL) and VDSL (Very-high-data-rate DSL). DSL 

technologies use complex modulation schemes to pack data onto copper wires. They 
are sometimes referred to as last-mile technologies because they are used only for 
connections from a telephone switching station to a home or office, not between 
switching stations. xDSL is similar to ISDN inasmuch as both operate over existing 
io copper telephone lines (POTS) and both require short runs to a central telephone 

office, usually less than 20,000 feet. However, xDSL offers much higher speeds - up 
to 32 Mbps for downstream traffic, and from 32 Kbps to over I Mbps for upstream 
traffic. 
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Appendix B: Video Server Technical Requirements 

The VirtualDVR applications build upon a foundation of high-capacity and high- 
performance video servers that can record digital television content from many 
5 concurrent IP multicasts and play recorded content back to subscribers over an IP 
network. 

The following outlines the specific extensions to and modifications of the Oracle Video 
Server (OVS) that are required to support the VirtualDVR framework. 

10 

Video Server Essential Requirements 
A/ Recording 

1 . A capability to set up, maintain, and tear down a recording session under 
software control is required. Since OVS will rely primarily on RTSP to set up, 

1 5 maintain, and tear down playback sessions, the use of the RTSP RECORD command, 
with suitable extensions may be used for this purpose. The command parameters 
must minimally permit the recording client (component) to specify: 

(a) Multicast source IP address and port. 

(b) Media format and bit rate. 

2 o (c) Date and time of day to begin recording (record in point). 

(d) Duration of time to record for. 

(e) A string prefix to be used to generate names for files created by the recording. 

2. The ability to record from IP multicasts of MPEG-2 single program transport 

2 5 streams is required. The video server must be capable of maintaining multiple (up to 

100) concurrent recording sessions. 

3. The video server must create an index that accurately relates the recorded 
media to the timeline of the source stream originating at the head end. In particular, 

3 o this index must accurately map out in time the locations of any media that may have 
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been dropped (i.e. not recorded) owing to IP packet loss or other transient conditions. 

4. Recording sessions must be robust and fault tolerant. In particular, the video 
server must maintain recording sessions under conditions of multicast IP packet loss 
and other transient conditions. 

5. The video server must maintain a control connection to the recording 

client to permit status queries and reports to be communicated between the recording 
server and client. In addition to responding to client requests for session information, 
the video server will be required to asynchronously send status information to the 
recording client in the event of significant changes to the status of recording sessions, 
such as persistent loss of signal. 

B. Media storage allocation and recovery 

1 . While recording sessions will typically span several hours, it is required that the 
video server will distribute the content recorded within each session over a series of 
file containers of equal capacity. This is required in order to facilitate incremental 
recovery of storage associated with a session and to minimize the effects of disk 
fragmentation on the continuous, high-volume, 24/7 recording service. 

2. It is required that these file containers be of exactly identical length, even if the 
video server requires that they begin and end on particular boundaries (e.g. l-frame or 
GOP boundaries). A relatively small amount of internal file fragmentation is of little 
consequence in comparison to the advantages of ensuring minimal external disk 
fragmentation. 

3. The index file that maps the recorded timeline (see A.3 above) must ensure the 
correct sequencing of the file containers that hold the actual media recorded within a 
recording session, in addition to mapping the time location of any media that may 
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have been dropped during the session. 

4. The video server must provide methods to permit VDVR applications to 
enumerate all recorded timelines available on the video server, including timelines that 
are in the process of being recorded. The video server must also provide methods to 
allow VDVR applications to retrieve associated metadata for each timeline, including 
(at least) the record in point (date & time), duration (normal play time, compensating 
for recording drop-outs and deleted file containers), media format, and bit rate. 

5. The video server must provide methods to permit VDVR applications to 
enumerate all of the file containers associated with a recorded timeline. 

6. The video server must provide methods to selectively delete file containers 
from 

within a timeline, without impacting the ability to play back other regions of the timeline 
where the associated file containers are available. This is required to permit media 
storage to be recovered progressively from the head of the timeline as the timeline 
ages out of the VDVR service window, and to permit file containers that are 
associated with regions of the timeline that are not referenced by any consumers to be 
recovered. 

C. Content locators and playback 

1 Named recorded timelines will form the basis for the generation of content 
locators URLs for playback clients. The play in and out points for content locators, 
expressed as millisecond offsets in relation to the record timeline (ie, in normal play 
time, irrespective of recording drop-outs and deleted file containers), will be included 
as modifiers in the URL. This is consistent with standard RTSP usage. 

2. The video server must provide a method to permit VDVR applications to 
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determine the viability of a content locator before including it in a play command. This 
can be expressed as a percentage of media indicated by the play in and out points 
that is actually available on the server. 

3. The video server must permit playback of content locators that are not 100% 
viable. The intention here is to allow playback of content locators that span recording 
drop-outs of short duration (e.g. a few seconds). For the present, it is acceptable if 
the video server simply "plays through" these drop-outs. 

D. Security 

1 . The video server must provide a method to allow a service administrator to 
register with the video server the IP addresses of the servers that will host VDVR 
recording clients. The video server must vet all recording requests against its 
database of registered VDVR servers and log and refuse all recording requests not 
originating from a registered DTVM host. 

2. The video server must also provide a method to prevent playback of content 
locators not brokered by VDVR. Conceptually, the authorization model must include 
the following capabilities: 

(a) The video server must provide a method to permit the application server to inform 
the video server that a particular client has the right to view a particular piece of 
content. 

(b) The video server must vet client requests to view recorded assets and refuse or 
grant these requests on the basis of access rights assigned by the application server. 

Oracle Video Server Support for VirtualDVR (DDVR) 
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A model provided by Oracle Corporation which meets the foregoing 
requirements and is used to support the VDVR is referred to as the Network DVR 
(NDVR). 

5 Scheduling and recurrence: From a subscriber's (consumer's) point of view, 

VirtualDVR record requests are templates or generators for individual program 
recordings (e.g. record all episodes of this program from this station, record a single 
episode from this station, record this program slot every weekday, etc). The 
VirtualDVR application retains complete control over recurring record requests in the 
10 NDVR model and this task is simplified by requiring only that the generated specific 
recording requests be added as rows to a subscriber recording table maintained by 
the video server. This table is used by the NDVR to calculate an optimal recording 
schedule that captures all generated requests as space permits. 

15 Consumer recording: The NVCR model does not require a predefined recording 

schedule to be maintained as all recording scheduling is performed on the server side 
by analysing the set of pending subscriber record requests. This enables subscribers 
to record programs from VirtualDVR-enabled stations at any time. 

20 Post facto recording: Post facto recording is a term used to refer to recording a 

program after the program's air date is past. The NDVR enables or disable post facto 
recording on a per-station basis and, when it is enabled, to continually record the 
station in a rolling recording window of sufficient duration to store any entire program 
(say, 4 hours). Any post facto subscriber recording requests can then be satisfied by 

2 5 retaining and not recycling the corresponding recorded media as it rolls off the rolling 

feed window. The NDVR also supports an opportunistic method of post facto 
recording that enables subscribers to request recordings for programs that have 
already started to broadcast. 

3 0 Recording sessions: The NDVR model maintains a table of all subscriber recording 



55 



CA 02321462 2000-09-29 



requests and analyses and coalesces these requests to generate an optimal schedule 
to drive the recording processes. The recording processes maintain status and end- 
point information in the subscriber requests table on a regular basis to provide nearly 
real time views of the status of in-progress subscriber recordings. This avoids any 
need for the service administrator to maintain a master recording schedule for each 
VirtualDVR-enabled station or for the VirtualDVR service to setup, maintain, and tear 
down live recording sessions in real time. 

Recorded program boundaries: A table of all subscriber recording requests is 
maintained and includes the record in and out points in each row. The inclusion of 
this information allows the video server to maintain complete control over the recovery 
and allocation of media storage without application (VDVR) intervention. 

Fault tolerant recording: The video server tolerates transient signal loss (i.e. dropped 
multicast packets) but terminates recording sessions if the input signal is lost for more 
than a few minutes. Restartable recording sessions may be used and the locations of 
persistent media loss may be visibly marked by playing a proxy clip to fill unrecorded 
gaps. 

Integrity metrics & playback: An integrity metric is required in order to enable the 
DTVM to inform subscribers in the event that one of their recorded programs contains 
regions of dropped media of significant extent. This may take the form of the number 
of minutes of dropped media (total for the recorded program) and the duration of the 
longest dropped region. In the event that an incompletely recorded program is 
requested for playback, the video server will play through short drop-outs and will play 
a proxy clip in place of longer drop-outs. 

Storage allocation: Since the VirtualDVR application may cohabit the same video 
server installation with other video server applications a fixed percentage of the 
available media storage is allocated to VirtualDVR using a global configurable setting. 
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The video server will accept subscriber record requests at any time and will make the 
determination of available storage space just before the respective air dates. 
Requests that cannot be satisfied due to low disk storage conditions are marked 
accordingly in the corresponding rows of the subscriber recording table. 

5 

Storage recycling: The NDVR records content to series of fixed-length files (segments) 
to minimize disk fragmentations and permit incremental recovery of storage allocated 
during recording sessions. Accordingly, the recovery process is driven using the 
information in the subscriber recordings table. The VirtualDVR is required to add and 
i o remove rows in the subscriber recording table as subscriber's request and delete 

recordings. The task of locating unreferenced segments and deleting them is handled 
entirely by a background process running on the video server at regular (e.g. hourly) 
intervals. 

1 5 Security and integrity: For each subscriber recording a row is maintained in the video 
server subscriber recording table that includes the record in and out points. This can 
take greater advantage of the end point information in the subscriber recording table 
to manage ticketing and to ensure the integrity of the subscriber end points during 
playback (i.e. to constrain consumer fast forward and rewind operations to remain 

2 0 within the recorded program boundaries). 

Distribution model: The NDVR model manages multiple VirtualDVR video servers 
comprised of a master server and a number of associated edge servers. A service 
administrator selects the high-demand stations and times and the VirtualDVR 
2 5 duplicates each recording request that falls within these stations and times on the 

master server and the edge server that is closest to the requesting subscriber. In this 
manner, most of the high-demand content is recorded to both the master and nearest 
edge servers and can be played back from either server, as required, to minimize 
network traffic. 

30 
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Administration: The NDVR model allows the video server to fully encapsulate the 
video server from a subscriber's perspective but some administrative and operational 
interfaces may not be completely hidden to the video server. OVS administrative and 
operational interfaces are used for certain aspects of VirtualDVR maintenance viz. 
server startup and shutdown. Direct interfaces between VirtualDVR administrators 
and operational personnel are minimized by using appropriately configured interfaces 
where desired. 
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What is claimed is: 

1 . An on-demand multimedia delivery system for use in an integrated multimedia 
broadcast delivery system extending from a broadcast provider to a subscriber, said 
broadcast delivery system comprising means for providing multimedia signals 
configured according to IP (Internet Protocol) format for multicast transmission over a 
broadband network and a system manager for providing interactive access to said 
multimedia signals by said subscriber through conversion means, being either a 
decoder in a set top box and a television or a decoder in a computer and a computer 
monitor, configured for converting said IP format signal into a format for display on 
said television or monitor, said on-demand delivery system comprising: 

(a) a central multimedia storage means located within said broadcast delivery 
system and remote from said subscriber for storing multimedia content; and, 

(b) an on-demand component configured for receiving a deliver request from a 
subscriber for said stored content, for locating said requested multimedia 
content from said storage means and for delivering said requested multimedia 
content to said conversion means for display on said television or monitor, 
wherein said multimedia content is stored in said storage means in a format 
configured for locating same in response to said deliver request. 

2. A system according to claim 2 wherein an interactive program guide (IPG) is 
provided to said subscriber for said access and said multimedia signals are 
transmitted 

through said network according to scheduling corresponding to said interactive 
program guide, said on-demand component being further configured for receiving a 
record request from a subscriber and for storing said multimedia content from said 
signals in response to said record request. 

3. A system according to claim 3 wherein said record request includes broadcast 
channel and time information identifying said multimedia content. 
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4. A system according to claim 3 wherein said record request is made from said 
interactive program guide. 

5. A system according to claim 4 wherein said multimedia content corresponds to 
a broadcast program. 

6. A system according to claim 5 wherein said multimedia content corresponds to 
multiple programs broadcast at the same time. 

7. A system according to claim 5 wherein said record request is received any 
time up to the end of transmission of said signal corresponding to said program. 

8. A method for on-demand delivery of multimedia content to a subscriber using a 
broadcast delivery system extending from a broadcast provider to a subscriber, said 
broadcast delivery system comprising means for providing multimedia signals 
configured according to IP (Internet Protocol) format for multicast transmission over a 
broadband network and a system manager for providing interactive access to said 
multimedia signals by said subscriber through conversion means, being either a 
decoder in a set top box and a television or a decoder in a computer and a computer 
monitor, configured for converting said IP format signal into a format for display on 
said television or monitor, said method comprising: 

(a) providing a central multimedia storage means within said broadcast delivery 
system and remote from said subscriber for storing said multimedia content; 

(b) receiving a deliver request from a subscriber for said stored content; 

(c) locating said requested multimedia content from said storage means; and, 

(d) delivering said requested multimedia content to said conversion means for 
display on said television or monitor, wherein said multimedia content is stored 
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in said storage means in a format configured for locating same in response to 
said deliver request. 

9. A method according to claim 8 whereby said system manager provides an 
interactive program guide (IPG) to said subscriber for said access and said multimedia 
signals are transmitted through said network according to scheduling corresponding to 
said interactive program guide, and further comprising receiving a record request from 
a subscriber and storing said multimedia content from said signals in response to said 
record request. 

1 0. A method according to claim 9 whereby said record request includes broadcast 
channel and time information identifying said multimedia content. 

11. A method according to claim 1 0 whereby said record request is made using 
said 

interactive program guide. 

12. A method according to claim 1 1 whereby said multimedia content corresponds 
to 

a broadcast program. 

1 3. A method according to claim 1 2 whereby said multimedia content corresponds 
to 

multiple programs broadcast at the same time. 

14. A method according to claim 13 whereby said record request is received any 
time up to the end of transmission of said signal corresponding to said program. 
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